============================================================== Guild: wafer.space Community Channel: 📐 - Designing / 💻-digital After: 2026-04-30 11:59 p.m. Before: 2026-06-01 12:00 a.m. ============================================================== [2026-05-02 8:34 a.m.] zhekar1998 Hi! If we have some 1024x64 or 1024x32 SRAM Macro? [2026-05-02 9:04 a.m.] mole99 You can find the foundry provided SRAMs here: https://github.com/wafer-space/gf180mcu/tree/main/gf180mcuD/libs.ref/gf180mcu_fd_ip_sram/gds They are 8 bits wide, so you'll need to use several in parallel. There are also community-designed 3.3V SRAMs, but they haven't been verified yet. [2026-05-12 11:05 p.m.] tholin Okay, I finally have a reproducible for the whole LVS gets stuck with my SCL issue Clone the SCL repo at `https://github.com/AvalonSemiconductors/gf180mcu_as_sc_mcu7t3v3` Open a terminal in example_project `nix-shell` `make clone-pdk` `make setup` `make` [2026-05-12 11:06 p.m.] tholin You can disable DRC to make it go faster [2026-05-13 8:12 p.m.] rtimothyedwards_19428 @Tholin : Here is a complete set of xschem symbols for your GF 3.3V standard cell library, if you could please add it under `libs.tech/xschem`. {Attachments} 2026-05_media/xschem-B805F.tgz [2026-05-15 12:23 a.m.] tholin Certainly. Good work. [2026-05-23 6:07 p.m.] zhekar1998 Hi everyone. This is my first public open-silicon review package, so I’d really appreciate ASIC/PD feedback. I built a compact 3.3V-only GF180 I/O candidate library for wafer.space/open MPW experiments: - 160um pad depth - 100 signal pads - ~17.3mm² usable core area - local DRC/LVS completed - LEF/CDL/SPICE/Liberty/IBIS generation - preliminary ngspice PVT/DC characterization - config/package generation flow included The project was developed using an automated agent-in-the-loop exploration flow with manual review and verification. Main goal: reduce padframe overhead for small GF180 SoCs. Any comments on architecture, verification flow, pad strategy, or obvious mistakes would be greatly appreciated. https://github.com/Detronyx-labs/gf180_compact_3v3_io.git {Embed} https://github.com/Detronyx-labs/gf180_compact_3v3_io.git GitHub - Detronyx-labs/gf180_compact_3v3_io: Compact open GF180MCU ... Compact open GF180MCU 3.3V-only I/O pad library candidate for wafer.space MPW: transistor-level pad cells, LEF/CDL/SPICE/Liberty/IBIS views, compact 160um padframe, I3C-capable bidirectional pads, ... {Reactions} waferspace ferrisCatOwO [2026-05-23 9:43 p.m.] zhekar1998 @Tim Edwards Hi Tim, I finally cleaned up and published my GF180MCU 3.3V 12T 2R2W SRAM macro experiment, which borrows from the transistor/layout concepts in your 512x8 reference. Repo (Apache-2.0): https://github.com/Detronyx-labs/gf180mcu-3v3-12t-2r2w-sram-macro To be completely honest, this is a fast AI-native / agentic design experiment — put together in about 3–4 days of intense work alongside Codex/LLM to see how far an automated open flow could push a custom multi-port layout. It is definitely not tapeout signoff collateral yet. If you (or anyone here) have a few minutes to glance at the README, I’d love to get a brutal reality check from actual silicon experts on a few things: Physical & Escape Routing: Are the 12T bitcell layout and shared M4/M5 escape assumptions physically defensible for GF180, or are we begging for major EM/IR-drop failures during simultaneous 2R/2W operations? Extraction limitations: My local Magic techfile isn't emitting capacitance coefficients for this flavor, so we’re stuck using an OpenRCX geometry-fallback proxy for timing (which throws warnings). How critical is it to escape open-source PEX fallbacks for a custom multiport memory structure like this? Prioritization: We have open items for full-macro LVS on row-edge boundaries, Liberty generation, and SNM/read-disturb sweeps. What should we absolute priority-target next to move this closer to tapeout-intent collateral? Your documentation was a lifesaver for understanding practical GF180 implementation, so any feedback on where this automated flow breaks down in the real world would be awesome. Thanks! {Embed} https://github.com/Detronyx-labs/gf180mcu-3v3-12t-2r2w-sram-macro GitHub - Detronyx-labs/gf180mcu-3v3-12t-2r2w-sram-macro: Open 12T 2... Open 12T 2R2W SRAM hard macro for GF180MCU 3.3V. Contribute to Detronyx-labs/gf180mcu-3v3-12t-2r2w-sram-macro development by creating an account on GitHub. 2026-05_media/gf180mcu-3v3-12t-2r2w-sram-macro-F6DF1 {Reactions} ❤️ [2026-05-24 2:42 a.m.] namibj I've been working with Tim to get full-die PEX into a state that's reasonably considered "functional" for smoke testing with Xyce; a major block to using it for fancier behavioral testing is the need to use a separate digital logic simulator (verilator or so? not sure what exactly tbh.) to find FF/latch states of the entire chip at the desired jump-off point for a transient test run, and associating those to the individual signals in the chip to synthesize `.nodeset` commands that force the chip into that desired starting state with an initial DC-operating-point solution, from where it'd then continue settling a DC solution from that moment on that doesn't have the signals pegged to hard VDD/VSS anymore, followed by a few clocks of progress to let at least a bit of PDN parasitics settle in, before then doing the actual state changes of desired concern. The extraction into Xyce-compatible PEX with _a lot_ of parasitic resistance and capacitance modeled is already working though; there's just a bit of scaling performance that seems to be left. If you want I can test extraction on that macro later. I need for that to work only top-level pins to be labeled; the rest will be flattened in KLayout if it's not already flattened, before I feed it to the PEX. [2026-05-24 3:05 a.m.] namibj @Zhekar1998 Also if you're willing I'd love to talk a bit about how us two have been doing agentic "PCell" construction: - you with the 12t-2r2w gf180mcuD sram, using Codex, - I with so far a base MCML VCO cell but soon also the other base SerDes component cells (XOR2, MUX2, D-latch at least) on sky130A but with a bit of luck I can port that to gf180mcuD (in time to get a base demo VCO clocking an output MUX that's fed with a 16-wide PBRS-31 generator) into Run2), using Jules. [2026-05-24 3:33 a.m.] namibj The gds from `gf180mcu_3v3_12t_2r2w_sram_512x8` seems to short the VSS PDN columns of the top level cell due to misalignment across the VSS colunn and ` c3_r1_rbl` of the 4x4 block. Please get at least basic LVS verification going before suggesting humans other than you yourself should look at the layout and give their opinions. Exceptions would apply if without having to open a zipfile I could easily see that you're disclaiming that level of integration LVS to have been done. [2026-05-24 3:42 a.m.] zhekar1998 Thanks! Its interesting because I do LVS all times in every runs, I recheck it now [2026-05-24 3:47 a.m.] zhekar1998 Yes I find it. sorry I do some mistake in rules [2026-05-24 3:48 a.m.] zhekar1998 I'll repear it and double check it by hands today))) [2026-05-24 3:49 a.m.] namibj I don't know how you do that LVS but I suggest you attempt to do it on a flattened layout to check the hierarchy isn't causing problems. It's hard to pin-point problems that way, but I'm pretty sure a basic abstracted-transistors (N/P and 3/4 pins) should be very much practical and a reliable check via graph-matching should be not-a-problem. [2026-05-24 3:52 a.m.] namibj I have no idea what timezone you're sleep/wake cycle corresponds to; I am as mentioned interested in talking to you (German or English, your choice) about the flow and struggles of this agentic-scripted-cells flow. Just in case you may be interested, that is. [2026-05-24 3:53 a.m.] zhekar1998 I'm in GMT +2 but. I will be hapy to speak about this [2026-05-24 3:55 a.m.] namibj oh same great then. I've got a bit of stuff to do offline but in like 2 hours I'd have time to talk. Sent you a DM for further discussing of that. {Reactions} 👍 [2026-05-24 3:40 p.m.] zhekar1998 I fix it now. Its was mistake with logic of generator script. [2026-05-26 2:02 p.m.] mithro_ @Greg - You where interested in this? [2026-05-26 2:11 p.m.] 246tnt It's ... LLM generated garbage ... [2026-05-26 2:47 p.m.] namibj I'll see to it; though this weekend including Monday+Tuesday (recovery) I'll be running on fumes, trade fair intense and weather melting. [2026-05-26 2:49 p.m.] 246tnt It'd be faster to start from scratch [2026-05-26 2:55 p.m.] namibj I meant I'm gonna talk to them about their methodology in the general endeavor "vibe coding PCell/macro-generator". I don't like it when people drop _broken_ slop at one's feet and request through whatever phrasing/request that one should code-review the _broken_ slop. {Reactions} 👍 [2026-05-26 3:29 p.m.] zhekar1998 To give you the full picture: OpenRAM isn't available for GF180MCU at all, so I had to find a workaround for my project. I didn't just raw-prompt an LLM — I actually ran it in a verification loop with KLayout, Magic, and Netgen-LVS until it passed for my two specific configurations. That said, I'm still just learning VLSI fundamentals, and I totally understand that an LLM-in-the-loop hack doesn't replace a proper, scalable macro-generator methodology. I’d love to join the discussion on how to build a robust generator the right way from scratch. I fully understand about this project can have mistakes but, without mistakes its imposible to learn. [2026-05-26 3:31 p.m.] zhekar1998 I try to build pipline where LLM will be generate code from big blocks and transistors. but not allways I can find generation mistaces [2026-05-26 3:33 p.m.] mole99 Staf will port his [flexmem SRAM generator](https://gitlab.com/Chips4Makers/c4m-flexmem) to gf180mcu for ws-run #2. {Embed} https://gitlab.com/Chips4Makers/c4m-flexmem Chips4Makers / c4m-flexmem · GitLab A flexible, scalable memory generator. 2026-05_media/twitter_card-570ddb06edf56a2312253c5872489-60AF3.jpg [2026-05-26 3:35 p.m.] zhekar1998 Oh thanks, I'll check it, Its can be helpfull [2026-05-28 7:36 a.m.] rebelmike Started a thread. ============================================================== Exported 29 message(s) ==============================================================